As an aside, I am wondering about using scm-diff-editor or something like it as a file selector for external diff tools and merge tools that don't have good support for directory comparison like p4merge, vimdiff (though there are other workarounds there), VS Code, etc.

This is related to a suggestion I once made on Discord to allow scm-diff-editor to launch external difftools.

OTOH, we could go into the opposite direction and use something much simpler than scm-diff-editor, e.g. https://github.com/lotabout/skim#use-as-a-library.

Out of curiosity, what's the benefit of API-level integration?

It's really nice that we have an integrated diff/merge editor, but I think it could also be achieved by spawning a separate binary or hidden jj subcommand (like jj scm-diff-editor.) Since we can't drop support for external tools, using the existing entry point might be simpler.

@yuja I want to integrate scm-record more tightly with jj, in particular:

• To support splitting into any number of commits, not just two.
• To edit commit messages inline (launch JJ_EDITOR or whatever).

Also, you could potentially avoid materializing large (binary?) files on disk, since they're only rendered as hashes in the UI.

We don't have an interface to communicate that kind of thing with the difftool/mergetool, and, since no other tools support anything like that (as far as I know?), it would just slow down development to try to create a stable command-line interface to do all that. We can establish an interface later if someone else ever tries to make such a tool.

As an aside, I am wondering about using scm-diff-editor or something like it as a file selector for external diff tools and merge tools that don't have good support for directory comparison like p4merge, vimdiff (though there are other workarounds there), VS Code, etc.

@ilyagr That sounds reasonable and in-scope to me, although scm-record might have to recompute a diff in that case in order to render it after delegating to the external difftool. Computing a new diff could be a little involved because the VCS can often compute more sensible diffs than scm-record (it may know to ignore whitespace, etc., on the request of the user). I suppose that's another scenario where tight coupling between the VCS and scm-record would help.

OTOH, we could go into the opposite direction and use something much simpler than scm-diff-editor, e.g. https://github.com/lotabout/skim#use-as-a-library.

Skim will probably be better indefinitely for keyboard shortcuts and fuzzy-matching, since it's hard to get good UX for that kind of thing (e.g. supporting Vim, Emacs, OS keybindings in text areas), and it's hard to compose TUI tools/libraries in Rust-land (can't just embed Skim into the scm-record interface somehow). It would be ideal to be able to search through files (and file contents) in scm-record, but there are only so many hours in the day!

This commit will probably need another look for the latest MergedTree changes.